With the rapid growth of mobile communication and great progress of technology, the world will move towards a fully interconnected network society where anyone or any device can acquire information and share data anytime and anywhere. It is estimated that there will be 50 billion interconnected equipments by 2020, of which only about 10 billion may be mobile phones and tablet computers. The rest are not machines communicating with human beings but machines communicating with one another. Therefore, how to design a system to better support the Internet of Everything is a subject needing further and intensive study.
In the standard of Long Term Evolution (LTE) of the Third Generation Partnership Project (3GPP), machine-to-machine communication is called machine type communication (MTC). MTC is a data communication service that does not require human participation. Deployment of large-scale MTC user equipments (UE) can be used in fields such as security, tracking, billing, measurement and consumer electronics; and the specific applications of large-scale MTC user equipments include video monitoring, supply chain tracking, intelligent meter reading, remote monitoring, etc. MTC requires lower power consumption and supports lower data transmission rate and lower mobility. The current LTE system is mainly for man-to-man communication services. The key to achieving the competitive scale advantages and application prospects of MTC services is that the LTE network supports low-cost MTC equipments.
In addition, some MTC equipments need to be installed in the basement of a residential building or at a position within the protection of an insulating foil, a metal window or a thick wall of a traditional building; as compared with the conventional equipment terminals (such as mobile phones and tablet computers) in LTE networks, the air interfaces of these MTC equipment swill obviously suffer from more serious penetration losses. 3GPP decides to study the project design and performance evaluation of MTC equipments with enhanced additional 20 dB coverage. It should be noted that MTC equipments located at poor network coverage areas have the following characteristics: extremely low data transmission rates, low latency requirements, and limited mobility. In view of the above characteristics of MTC, the LTE network can further optimize some signaling and/or channels to better support MTC services.
Therefore, at the 3GPP RAN #64 plenary session held in June 2014, a new MTC work item with low complexity and enhanced coverage for Rel-13 was proposed (see non-patent literature: RP-140990 New work Item on Even Lower Complexity and Enhanced Coverage LTE UE for MTC, Ericsson, NSN). In the description of this work item, an LTE Rel-13 system needs to support uplink/downlink 1.4 MHz RF bandwidth for an MTC user equipment to operate at any system bandwidth (for example, 1.4 MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz, or 20 MHz). The standardization of the work item would be completed at the end of 2015.
In addition, for better implementation of the Internet of Everything, at the 3GPP RAN #69 plenary session held in September 2015, a new work item was further proposed (see non-patent literature: RP-151621 New Work Item: NarrowBand IOT (NB-IOT), which may be called narrowband Internet of Things (NB-IOT). In the description of this item, NB-IOT needs to support uplink/downlink 180 KHz RF bandwidth and three modes of operation (deployment mode): stand-alone mode of operation, guard-band mode of operation, and in-band mode of operation. The stand-alone mode of operation is to implement NB-IOT on the existing GSM frequency band, i.e., using the operating frequency band of an existing GERAN system and a scattering frequency band potentially deployed by the IOT. The guard-band mode of operation is to implement NB-IOT in the guard band of one LTE carrier, i.e., using a frequency band in the LTE frequency band that is used as the guard band. The in-band mode of operation is to implement NB-IOT in the existing LTE frequency band, i.e., using the frequency band in the LTE frequency band for actual transmission. Different bearer modes may adopt different physical parameters and processing mechanisms.
The 3GPP RAN1 working group concluded that NB IoT physical resource blocks (PRBs) are divided into anchor PRBs and non-anchor PRBs. The anchor PRB can be used for transmitting data related to NB-IoT, such as a master system information block (MIB), a primary synchronization signal (PSS)/secondary synchronization signal (SSS), or a system information block (SIB), while the non-anchor PRB can be used only by a user equipment to receive or send data for unicast transmission related to NB-IoT, such as a physical downlink control channel (PDCCH), a physical downlink shared channel (PDSCH), or a physical uplink shared channel (PUSCH). A PRB already used for transmitting MIB, PSS/SSS, or SIB data related to NB-IoT cannot be used as a non-anchor PRB. When an eNB does not configure a non-anchor PRB for the UE, the anchor PRB may also be used by the user equipment (UE) to receive or send data related to NB-IoT for unicast transmission such as a PDCCH, a PDSCH, or a PUSCH. A base station (e.g., an eNB) may configure a non-anchor PRB for the UE through a radio resource control (RRC) connection establishment message, an RRC connection reestablishment message, an RRC reconfiguration message, an RRC resume message, or the like.
According to whether frequency bands to which frequencies of an anchor PRB accessed by the UE and a non-anchor PRB allocated by the eNB to the UE belong are an in-band frequency band of LTE, a guard band frequency band of LTE, or a frequency band of the stand-alone mode of operation (for example, the GSM frequency band), the following anchor PRB and non-anchor PRB combination modes may exist (1) in-band to in-band; that is, the anchor PRB and the non-anchor PRB are both in-band PRBs (the frequency bands of the anchor PRB and the non-anchor PRB are both an in-band frequency band); (2) in-band to guard band; that is, the anchor PRB is an in-band PRB and the non-anchor PRB is in the guard band (the anchor PRB is in the in-band frequency band and the non-anchor PRB is in the guard band frequency band); (3) guard band to guard band; that is, the anchor PRB and the non-anchor PRB are both in the guard band (the frequency bands of the anchor PRB and the non-anchor PRB are both the guard band frequency band); (4) guard band to in-band; that is, the anchor PRB is in the guard band and the non-anchor PRB is an in-band PRB (the anchor PRB is in the guard band frequency band and the non-anchor PRB is in the in-band frequency band); and (5) stand-alone to stand-alone; that is, the anchor PRB and the non-anchor PRB are both in a frequency band suitable for the stand-alone mode of operation (for example, the GSM frequency band).
Based on the different combination modes of the anchor PRB and the non-anchor PRB described above, how to configure a non-anchor PRB for the UE so that the UE can determine the frequency of the non-anchor PRB to receive or send, on the non-anchor PRB, data related to NB-IoT for unicast transmission such as a PDCCH, a PDSCH, or a PUSCH is a problem that needs to be addressed.